feat: scope CVE fixes to affected container and improve CVE verification#96
Merged
jwm4 merged 5 commits intoambient-code:mainfrom Mar 31, 2026
Merged
Conversation
Contributor
WalkthroughCVE-fixer docs and workflow now parse Jira summaries for container and package, prefer container-scoped repo selection (matching Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Jira as Jira (issue summary)
participant WF as CVE-Fixer Workflow
participant Selector as Repo Selector (component mappings)
participant Scanner as Vulnerability Scanner
participant Manifests as Manifest Checker
participant Decider as Decision Logic
participant Fixer as Fix Automation
Jira->>WF: issue created/updated (summary with container/package)
WF->>Selector: extract CONTAINER & PACKAGE -> resolve repos (container_to_repo_mapping -> filter by subcomponent)
Selector-->>WF: selected repo chain(s) or fallback list with warning
WF->>Scanner: run repo/image vulnerability scan
WF->>Manifests: check manifests for PACKAGE + versions
Scanner-->>Decider: scan results (CVE present/absent)
Manifests-->>Decider: package-version evidence (vulnerable/not found/not vulnerable)
Decider->>WF: decide: already fixed (both absent) OR proceed with fixes
alt proceed with fixes
WF->>Fixer: apply fixes / create PRs across selected repos
Fixer-->>WF: fix artifacts (PRs, backports, notes)
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@workflows/cve-fixer/.claude/commands/cve.fix.md`:
- Around line 72-76: The PACKAGE extraction regex (used in the PACKAGE variable)
doesn't match npm scoped names with '@' or '/' (e.g., `@babel/core`); update the
grep -oP lookbehind regex used for PACKAGE to expand the character class to
include '@' and '/' (for example replace [\w._-]+ with a class that includes @
and / such as [@\w./-]+ or a more specific scoped-package pattern) so PACKAGE
correctly captures scoped npm package names; leave the CONTAINER extraction
unchanged.
In `@workflows/cve-fixer/component-repository-mappings.json`:
- Around line 486-510: The upstream entry
"llm-d/llm-d-workload-variant-autoscaler" uses a different repository name than
the midstream "opendatahub-io/workload-variant-autoscaler" (and
red-hat-data-services counterpart), which prevents the chain-resolution logic
described in cve.fix.md Step 3.1 from matching them; fix by either renaming the
upstream key to "llm-d/workload-variant-autoscaler" (so the base repo name
matches the midstream/downstream keys) or, if the upstream intentionally uses
the llm-d- prefix, add an explicit clarifying note in the upstream object's
"branch_strategy" or add a new field (e.g., "canonical_name") that the workflow
will use to resolve same-name repos; update the JSON for
"llm-d/llm-d-workload-variant-autoscaler" or adjust workflow logic to use the
new canonical field accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: e555d207-3c0b-490a-be65-5a258bb76228
📒 Files selected for processing (2)
workflows/cve-fixer/.claude/commands/cve.fix.mdworkflows/cve-fixer/component-repository-mappings.json
Comment on lines
+72
to
+76
| ```bash | ||
| SUMMARY="CVE-2025-66418 rhoai/odh-llm-d-routing-sidecar-rhel9: urllib3: Unbounded decompression" | ||
| CONTAINER=$(echo "$SUMMARY" | grep -oP '(?<=CVE-[0-9]+-[0-9]+ )[\w/.-]+(?=:)') | ||
| PACKAGE=$(echo "$SUMMARY" | grep -oP '(?<=: )[\w._-]+(?=:)') | ||
| ``` |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Package regex may miss npm scoped packages.
The regex [\w._-]+ won't match npm scoped package names that contain @ and / (e.g., @grpc/grpc-js, @babel/core). Consider expanding the character class.
📝 Suggested fix
- PACKAGE=$(echo "$SUMMARY" | grep -oP '(?<=: )[\w._-]+(?=:)')
+ PACKAGE=$(echo "$SUMMARY" | grep -oP '(?<=: )[@\w./_-]+(?=:)')🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@workflows/cve-fixer/.claude/commands/cve.fix.md` around lines 72 - 76, The
PACKAGE extraction regex (used in the PACKAGE variable) doesn't match npm scoped
names with '@' or '/' (e.g., `@babel/core`); update the grep -oP lookbehind regex
used for PACKAGE to expand the character class to include '@' and '/' (for
example replace [\w._-]+ with a class that includes @ and / such as [@\w./-]+ or
a more specific scoped-package pattern) so PACKAGE correctly captures scoped npm
package names; leave the CONTAINER extraction unchanged.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@workflows/cve-fixer/.claude/commands/cve.fix.md`:
- Around line 305-307: Update the "Package not found in any manifest" handling
to avoid blindly adding/pinning dependencies: change the behavior and docs so
the workflow does NOT auto-add a direct dependency but instead suggests
ecosystem-appropriate actions (for Go recommend using a `replace` directive; for
Python recommend documenting potential conflicts with adding to requirements.txt
and suggesting pinning in the project’s lockfile or asking the maintainer to
adjust; for npm recommend using `overrides` as noted in Step 8.1). Modify the
text under "Package not found in any manifest" to present these per-ecosystem
recommendations and change the automated fix step to create a non-destructive PR
template that proposes the recommended approach and flags manual review rather
than applying an automatic pin.
- Around line 121-138: Add documentation for the missing branch when a CONTAINER
is extracted but not found in container_to_repo_mapping: describe a new Step
3.1.1 that logs a warning (e.g., "⚠️ CONTAINER not found in
container_to_repo_mapping — processing all component repos") and falls back to
the Step 3.2 behavior of processing all repositories in the component (so the
CVE scan in Step 5 can filter irrelevant repos); reference CONTAINER,
container_to_repo_mapping, and the existing 3.1/3.2 flow so readers can see this
is the fallback path when lookup returns no match.
In `@workflows/cve-fixer/component-repository-mappings.json`:
- Around line 381-385: The mapping for container key
rhoai/odh-llm-d-routing-sidecar-rhel9 points to
red-hat-data-services/llm-d-routing-sidecar which is the only repo with
subcomponent "routing-sidecar", producing a dead-end chain per Step 3.1 of
cve.fix.md; update the component-repository-mappings.json by adding a brief
inline comment or a notes field next to the container_to_repo_mapping entry
(referencing rhoai/odh-llm-d-routing-sidecar-rhel9 and
red-hat-data-services/llm-d-routing-sidecar and the subcomponent
"routing-sidecar") stating that upstream is archived and CVE fixes only apply to
the downstream repo so reviewers/automation know this is intentional.
- Around line 600-614: The subcomponent "lm-evaluation-harness" is incorrectly
assigned to trustyai-service-operator repos, causing unrelated repos to be
grouped; update the JSON entries for
"trustyai-explainability/trustyai-service-operator",
"opendatahub-io/trustyai-service-operator", and
"red-hat-data-services/trustyai-service-operator" to use a distinct subcomponent
(e.g., "trustyai-operator") while leaving "opendatahub-io/lm-evaluation-harness"
and "red-hat-data-services/lm-evaluation-harness" as "lm-evaluation-harness";
ensure the cve_fix_workflow primary_target/backport_targets remain unchanged and
validate the subcomponent key for each affected repo block
("trustyai-service-operator" entries) so the CVE collection logic described in
Step 3.1 will only match repos that truly belong to the same container chain.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 0351e3fa-049f-4589-bfe7-f615379b3fc7
📒 Files selected for processing (2)
workflows/cve-fixer/.claude/commands/cve.fix.mdworkflows/cve-fixer/component-repository-mappings.json
- Parse container name and package from Jira ticket summary in Step 1 - Use container_to_repo_mapping in Step 3 to scope PRs to only the repos that build the affected container, not all component repos. Fallback to all repos when container cannot be parsed. - Add package version check (Step 5.2.1) alongside existing scanner: when scan doesn't find CVE, check dependency manifests directly (requirements.txt, go.mod, package.json) before skipping. Only skip when both scan AND version check find no evidence of the vulnerability. If package not found in manifests, still create PR with manual review note. - Add AI Evaluations full repo chain (ragas, garak, lm-evaluation-harness, trustyai-service-operator, eval-hub) with container mappings Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
Add subcomponent field to repos in Model as a Service, llm-d, and AI Evaluations so cve.fix can identify which upstream/midstream/downstream repos belong to the same container chain. - cve.fix Step 3 now uses subcomponent to scope PRs to the affected container's chain only; falls back to all component repos (with scan-based filtering) when subcomponent is not defined - Add missing AI Evaluations container mappings (eval-hub, garak) and ragas repo chain (upstream/midstream/downstream) Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
Allow users to optionally scope cve.find to a specific subcomponent: /cve.find llm-d autoscaler /cve.find "AI Evaluations" trustyai-ragas Reverse-looks up all containers for the given subcomponent from component-repository-mappings.json and adds pscomponent: label filters to the JQL using OR when multiple containers exist (e.g. lm-evaluation-harness has both odh-ta-lmes-driver and odh-ta-lmes-job containers). cve.fix requires no changes — it reads from the scoped find output and its container-based repo scoping handles the rest automatically. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
- Fix subcomponent: trustyai-service-operator repos incorrectly grouped under lm-evaluation-harness — give them their own subcomponent value - Add missing case in Step 3: container extracted but not found in container_to_repo_mapping → fall back to all repos with warning - Add language-specific transitive dependency guidance in Step 5.2.1: Go (replace directive), Python (update parent package), Node (overrides) - Fix package regex to support npm scoped packages (@grpc/grpc-js etc) Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
vmrh21
force-pushed
the
improve-cve-fix-repo-scoping
branch
from
64798e0 to
9d8c9c5
Compare
- AutoML: maps to pipelines-components upstream/midstream/downstream chain with container managed-open-data-hub/odh-automl-rhel9 - AutoRAG: same pipelines-components chain plus IBM/ai4rag as upstream-only Python package (excluded from automation — CVEs manifest as container CVEs in pipelines-components, fix by updating ai4rag version there) - Both confirmed as distinct Jira component names (AutoML, AutoRAG) Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Test results with new changes: Find works perfectly, fix is something we will have to test out when we have actual cves reported against these subcomponents we have access to |
Contributor
Author
|
Final list of components mapping present in the mapping file which maps |
Contributor
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
workflows/cve-fixer/component-repository-mappings.json (1)
795-891: 🧹 Nitpick | 🔵 TrivialConsider adding
subcomponentto distinguish AutoML vs AutoRAG paths.Both AutoML and AutoRAG components share the same repositories (
pipelines-componentsmonorepo) but have nosubcomponentfield defined. Per the workflow logic incve.fix.mdStep 3.1, this means container-scoped lookups will fall back to processing all repos.Additionally, AutoRAG has an empty
container_to_repo_mapping(line 839), so container extraction will always trigger the fallback behavior.This works (the scan in Step 5 filters irrelevant repos), but adding subcomponents like
"automl"and"autorag"could reduce unnecessary processing when CVEs target specific paths within the monorepo.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@workflows/cve-fixer/component-repository-mappings.json` around lines 795 - 891, The AutoML/AutoRAG entries lack a subcomponent identifier, so container-scoped lookups fall back to processing all repositories; add a "subcomponent" field (e.g., "automl" for AutoML and "autorag" for AutoRAG) to the relevant repository objects and/or to the top-level entries (keys "AutoML" and "AutoRAG") and update the "container_to_repo_mapping" for AutoRAG to map container images to the appropriate repo+subcomponent; target the JSON objects under "AutoML" and "AutoRAG", the "container_to_repo_mapping" entries, and the per-repo "repositories" blocks (e.g., "red-hat-data-services/pipelines-components" and "kubeflow/pipelines-components") so the workflow can narrow lookups to the "automl" or "autorag" paths.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@workflows/cve-fixer/component-repository-mappings.json`:
- Around line 795-891: The AutoML/AutoRAG entries lack a subcomponent
identifier, so container-scoped lookups fall back to processing all
repositories; add a "subcomponent" field (e.g., "automl" for AutoML and
"autorag" for AutoRAG) to the relevant repository objects and/or to the
top-level entries (keys "AutoML" and "AutoRAG") and update the
"container_to_repo_mapping" for AutoRAG to map container images to the
appropriate repo+subcomponent; target the JSON objects under "AutoML" and
"AutoRAG", the "container_to_repo_mapping" entries, and the per-repo
"repositories" blocks (e.g., "red-hat-data-services/pipelines-components" and
"kubeflow/pipelines-components") so the workflow can narrow lookups to the
"automl" or "autorag" paths.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: bd9e2a48-1f2d-4456-988a-7c1a23fc54f6
📒 Files selected for processing (3)
workflows/cve-fixer/.claude/commands/cve.find.mdworkflows/cve-fixer/.claude/commands/cve.fix.mdworkflows/cve-fixer/component-repository-mappings.json
angaduom
approved these changes
Mar 31, 2026
Contributor
angaduom
left a comment
angaduom
left a comment
There was a problem hiding this comment.
thanks for running the tests, appreciate it
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
cve.fixnow parses the container name and package from the Jira ticket summary (e.g.rhoai/odh-llm-d-routing-sidecar-rhel9: urllib3) and usescontainer_to_repo_mappingto only process repos in that container's upstream/midstream/downstream chain — not every repo under the component. This prevents autoscaler CVEs from creating PRs in batch-gateway or inference-scheduler repos, and vice versa.Test plan
/cve.fix llm-dwith an inference-scheduler Jira ticket — verify only inference-scheduler repos get PRs, not batch-gateway or autoscaler repos/cve.fixwith a Python CVE ticket — verify package version check runs when pip-audit finds nothing/cve.fixwith a CVE where both scan and version check find nothing — verify it's correctly skipped🤖 Generated with Claude Code